Generated code - Fetching DataReaders and projections, SelfServicing

Preface

LLBLGen Pro v2 introduces two new ways of fetching a resultset: as an open IDataReader object and as a projection. This section discusses both and illustrates both with a couple of examples, either using a stored procedure or a query build using entity fields. Fetching a resultset as an open IDataReader is considered an advanced feature and should be used with care: an open IDataReader object represents an open cursor to data on a connected RDBMS over an open connection. This means that passing the IDataReader around in your application is not recommended. Instead use the IDataReader in the routine you also called the fetch logic to create it and immediately after that make sure the IDataReader gets closed and disposed. This way you're sure you'll free up resources early.

To understand projections better, it's recommended to first read the section about fetching an open IDataReader. Another section describing projections, but then related to an entity view object, is Generated code - using the EntityView class.

Fetching a resultset as an open IDataReader

To fetch a resultset as an open IDataReader, you call one of the overloads of GetAsDataReader, a method of the class TypedListDAO. There are two ways to use the GetAsDataReader method: by supplying a ready to use IRetrievalQuery or by specifying a fields list, and various other elements which are required for creating a new query by the Dynamic Query Engine (DQE). The first option, the IRetrievalQuery option, can be used to fetch a retrieval stored procedure as an open IDataReader, by using the RetrievalProcedures.GetStoredProcedureNameCallAsQuery() method of the particular stored procedure call. This is a generated method, one for every retrieval stored procedure call known in the LLBLGen Pro project.

GetAsDataReader accepts also a parameter called CommandBehavior. This parameter is very important as it controls the behavior the datareader should perform when the datareader is closed. It's required to specify a behavior different than CloseConnection if the fetch is inside a transaction and the connection has to stay open after the datareader has been closed. On SelfServicing, it's especially recommended to set CommandBehavior to CloseConnection, as closing the connection can be a little problematic, because it's abstracted away from you.

It's recommended to familiar yourself with the various overloads of the GetAsDataReader method using the LLBLGen Pro reference manual. The method is defined on DaoBase, the base class of the TypedListDAO class.

It's possible to construct your own IRetrievalQuery object with your own SQL, by instantiating a new RetrievalQuery object. However in general, it's recommended to use the GetAsDataReader overloads which accept a fieldslist and other elements and let LLBLGen Pro generate the query for you.

Fetching a Retrieval Stored Procedure as an IDataReader

An example of calling a procedure and receive a datareader from it is enlisted below. It calls the Northwind stored procedure CustOrdersOrders which returns a single resultset with 4 fields. The example simply prints the output on the console.
The VB.NET example uses a try / finally block as VB.NET for .NET 1.x doesn't support the Using statement. Users of VB.NET for .NET 2.0 can replace the try/finally block with the new Using statement as illustrated in the C# example.

Fetching a Dynamic List as an IDataReader

An example of a dynamic list which is used to receive a datareader from it is enlisted below. The example simply prints the output on the console.

Resultset projections

In the previous section we've seen that a query could be fetched as an open IDataReader, where the query could be an IRetrievalQuery object containing a stored procedure call, or a dynamic formulated query from fields, a filter and other elements you might want to use in the query. It is then up to you what to do with the IDataReader. It's likely you'll project the data available to you through the IDataReader object onto a data-structure. Projecting a resultset is a term from the relational algebra, the Wikipedia has a formal explanation of it: Projection (relational algebra) (opens in a new window). It comes down to the fact that you create a new set of data from an existing set of data. The existing set of data is the resultset you want to project. The new set is the projection result.

LLBLGen Pro offers two different projection mechanisms: projecting an EntityView (see: Generated code - using the EntityView class) and projecting a fetched resultset, which is discussed here. Both mechanisms are roughly the same, only the source data origin differs and the used interface implemented by the used projection engine. The projections of entity view data are a little more advanced because it's possible to execute in-memory filters on the entity object itself to make a selection which field to project. This means that the projector objects, as discussed in the EntityView Projection documentation, are both implementing the IDataValueProjector, but the projector objects used for EntityView projections also implement the interface derived from IDataValueProjector, IEntityPropertyProjector. For projections of EntityView data, EntityPropertyProjector objects are used, for projections of resultset data, the more simpler DataValueProjector objects are used. Their meaning is roughly the same, so if you're familiar with EntityView projections, you'll directly understand the examples below using DataValueProjector objects. As the projection engine interfaces required for both mechanisms are fairly similar, the shipped projection engines thereby can be used for both mechanisms.

Resultset projections are done by an IGeneralDataProjector implementation. IGeneralDataProjector allows an object[] array of values to be projected onto new instances of whatever class is supported by the IGeneralDataProjector implementation, for example new entities or a DataRow in a DataTable. Which values in the object[] array are projected onto which properties of the target element, created by the IGeneralDataProjector implementation, is specified by the specified set of IDataValueProjector implementations passed in. In the following examples you'll see the usage of the projection engines is similar to the usage of the projection engines in the EntityView projection examples.

In SelfServicing, the TypedListDAO class, available in the DaoClasses namespace of the generated code, has a method called GetAsProjection with various overloads. This method produces the projection of the resultset defined by the input parameters (similar to the GetAsDataReader method) or the resultset passed in in the form of an open IDataReader object. By which projection engine the projection is performed as well which data is projected is passed in as well. GetAsProjection doesn't return a value, the result is in the projection engine object. This method has similar overloads as GetAsDataReader, though it doesn't accept a commandbehavior: if a connection is open, it leaves it open, if no connection is open, it creates one and closes one afterwards.

Projecting Stored Procedure resultset onto entity collection

For this stored procedure projection example, the following stored proecdure is used:

CREATE  procedure pr_CustomersAndOrdersOnCountry
	@country VARCHAR(50)
AS
SELECT * FROM Customers WHERE Country = @country
SELECT * FROM Orders WHERE CustomerID IN
(
	SELECT CustomerID FROM Customers WHERE Country = @country
)

which is a SqlServer stored procedure and which returns 2 resultsets: the first is all customers filtered on a given Country, and the second is all orders of those filtered customers.

The stored procedure is fetched as an open IDataReader and both resultsets are projected onto entity collections: the first resultset on a CustomerCollection object and the second on an OrderCollection object. The stored procedure uses a wildcard select list. This is for simplicity. The code below is written using .NET 1.x for clarity. .NET 2.0 users are encouraged to use the generic variants of the discussed classes instead, as discussed also in Generated code - using the EntityView class.

Projecting Dynamic List resultset onto custom classes

We can go one step further and create a fetch of a dynamic list and fill a list of custom class instances, for example for transportation by a Webservice and you want lightweight Data Transfer Objects (DTO). The projecting a resultset onto custom classes is .NET 2.0 only, as the projection engine uses generics. Of course, you can write your own implementation of IGeneralDataProjector which performs class instantiation and property setting using reflection on .NET 1.x


Where the custom class is:

public class CustomCustomer
{
	#region Class Member Declarations
	private string _customerID, _companyName, _city, _country;
	#endregion

	public CustomCustomer()
	{
		_city = string.Empty;
		_companyName = string.Empty;
		_customerID = string.Empty;
		_country = string.Empty;
	}

	#region Class Property Declarations
	public string CustomerID
	{
		get { return _customerID; }
		set { _customerID = value; }
	}

	public string City
	{
		get { return _city; }
		set { _city = value; }
	}

	public string CompanyName
	{
		get { return _companyName; }
		set { _companyName = value; }
	}

	public string Country
	{
		get { return _country; }
		set { _country = value; }
	}
	#endregion
}